Exchange 2010 : Managing Exchange Recipients (part 4)

6. Importing and Exporting Mailboxes

Moving mailbox content to and from PSTs by using the ExMerge utility has been a normal function of an Exchange administrator's job. Although Exchange 2007 was released without a supported method to import and export mailboxes to PST files, this was promptly rectified in Service Pack 1 and again improved in Exchange 2010 and Exchange 2010 SP1. Importing or exporting a mailbox can be done using the EMS with the Import-Mailbox and Export-Mailbox cmdlets or if SP1 is installed the New-MailboxExportRequest and New-MailboxImportRequest cmdlets.

Note:

The Import-Mailbox and Export-Mailbox cmdlets are available in the initial release of Exchange 2010; however, they've been replaced with the New-MailboxExportRequest and New-MailboxImportRequest cmdlets.

By default no roles have rights to use any of the import or export cmdlets. You will have to add the rights to a role or user before these cmdlets are available. For example, to assign these rights to Alex, run New-ManagementRoleAssignment –Role "Mailbox Import Export" –User Alex. Or to assign the roles to an entire group named Import Export Group, run New-ManagementRoleAssignment –Role "Mailbox Import Export" –Group "Import Export Group".

After you assign the proper rights, a few additional prerequisites must be met before you can use Import-Mailbox or Export-Mailbox:

• When exporting data to a PST file, only one mailbox at a time can be exported.

• Importing or exporting data must be performed on a 64-bit computer with the Exchange Server 2010 role installed and the 64-bit version of Microsoft Outlook 2010. It is recommended that this be a computer dedicated for the purpose of importing and exporting mailbox data.

• The Import-Mailbox cmdlet cannot be used on servers running Exchange 2003 or Exchange 2007. You must use ExMerge on those servers and import data to a PST file.

• Public folder data can't be imported.

When you use the Import-Mailbox cmdlet, the mailboxes do not have to match. For example, you can import data from a mailbox named [email protected] to a mailbox named [email protected]. All messages from the transport dumpster are imported, and even hidden data, if it exists in the .pst, will be imported. When data is merged into the existing mailbox it will not import duplicated messages. By default, the Import-Mailbox cmdlet will empty all folders and subfolders. When using this cmdlet you have the option of including or excluding special folders, such as the following:

• Inbox

• Deleted Items

• Drafts

• Junk E-mail

• Outbox

• Sent Items

• Calendar

• Notes

• Journal

• Tasks

• Contacts

You export mailbox data by using the Export-Mailbox cmdlet in the EMS. Although the cmdlet has a limitation of only being able to export a single mailbox at a time, it does have nice features that allow you to delete associated messages or use filters to filter out messages based on recipients and senders. To filter on senders, use the SenderKeywords parameter. To filter on recipients, use the RecipientKeywords parameter. You can remove one or even multiple messages using the Export-Mailbox cmdlet. You might want to do this when a message is accidently sent to the wrong mailbox or when you need to process a mailbox for legal reasons.

Exchange 2010 SP1 replaces initial release cmdlets for importing and exporting mailboxes that use the MRS to perform the work. This new method has several benefits. One benefit is that Outlook no longer needs to be installed on the management workstation—all of the work is done by the MRS. The second benefit is that the import and export process can access both the primary and archive mailboxes.

After assigning permissions to the account that will be creating the import or export requests, you also need a file share accessible by the MRS to either import from or export to. The MRS server must have permissions to read and write to the file share. To ensure that all MRS instances have permissions to write to the share, you can assign permissions using the Exchange Trusted Subsystem group.

6.1. Exchange ActiveSync and Device Management

The last few years have seen a proliferation of devices that support Exchange ActiveSync. This allows users to choose devices that meet their needs and preferences, but at the same time increases the support burden on IT staff, who are needed to help support these devices.

These devices also support different types of policies, making it difficult to enforce a uniform policy across the board. And many companies like to control the devices that are allowed to store company data so as to better control security—in effect not allowing users to provide their own devices. Exchange 2010 improved the administrative control over which devices are allowed to connect with Exchange ActiveSync.

Exchange 2010 provides the ability for administrators and users to remotely wipe the stored information off of a mobile device that is connected with Exchange ActiveSync. This feature is particularly useful when a mobile device is lost or stolen because it will remove any personal information from the device.

Exchange 2010 SP1 provides additional help for administrators in ECP:

• Configure the access level granted to all devices by default.

• Set up e-mail alerts that will enable administrators to take action when a device is being quarantined.

• Personalize the message that is sent to users when their devices are being recognized or get quarantined.

• List quarantined devices.

• Create and manage ActiveSync Device Access Rules, permitting administrators to allow, block, or quarantine certain listed devices.

• Allow or block a device for a particular user.

• For each mailbox the Administrator will be able to:

  • Enumerate a user's devices.

  • Wipe device information wirelessly.

  • Remove old device partnerships.

  • Allow or block the given device for a particular user.

These new features allow administrators to quarantine unknown mobile devices and then approve or block them upon review. The devices can be allowed, quarantined, or blocked based on device type. If your company has standardized a specific mobile device, you can block all devices and then add a Device Access Rule that allows the specific device type.

When a device is quarantined or blocked an e-mail message is sent to the device that informs the user the status of the device. Alternatively, the policy can be configured to send an e-mail message to an administrator with information about the device, so that she can take action to allow the device if she chooses to do so.

7. Automating Administration

Although the Exchange 2010 management tools are easy to use and make quick work of most management tasks, common management tasks can be time-consuming. When administrators make manual changes, these are also prone to error. Many larger companies have adopted an integrated approach for creating mailboxes, public folders, and other Exchange objects. They do this by tying together core business systems such as payroll, security access systems, and Active Directory to ensure that one system feeds the other systems. This can ensure that when an employee is hired, all the necessary accounts and processes are completed to ensure that the employee gets paid and has access to the building and all of the computing systems. This type of automation is usually done with a meta-directory system such as Microsoft Forefront Identity Manager 2010. These systems take a lot of planning and usually some custom integration development to work in a large business. These systems can significantly reduce administrative burden by reducing manual effort in adding, creating, modifying, and deleting objects. They also reduce effort because less time is spent auditing to ensure that the manual processes are followed.

On a smaller scale, one way to automate some administration tasks is to create EMS scripts, which can provide a number of features that you can use to perform bulk recipient management. For simple tasks, you can pipe output between cmdlets to retrieve a list of appropriate objects, and then you can modify them. You can also use scripting for complex tasks, such as creating users from a .csv file.

One of the more advanced abilities of PowerShell is the ability to filter large sets of data. For example, you can specify a filter string to search for a subset of mailboxes when you run Get-User. To specify the custom filer you must use the Filter parameter or the RecipientFilter parameter. The filter must be specified in the OPATH querying language. The syntax of an OPATH filter is {(attribute operation 'value')}. The following cmdlet selects users with the Company attribute defined as Litware users:

Get-User -Filter {(Company -eq 'Litware')}

Additional parameters can be added to the filter. The following cmdlet selects users with the Company attribute defined as Litware and the Department attribute defined as Accounting:

Get-User -Filter {(Company -eq 'Litware') -and (Department -eq 'Accounting')}

					  

The common operators in an OPATH filter are:

• -and

• -eq (equals)

• -gt (greater than)

• -like (compares strings)

• -lt (less than)

• -ne (does not equal)

• -not

• -notlike (compares strings)

• -or

PowerShell has a comprehensive scripting engine. You can create scripts to perform advanced bulk-management tasks that are not possible with simple pipelining. Scripts can create more complex structures and consequently enable you to perform more complex tasks. Scripts can use loops, variables, reading and writing files, and more. If you are interested in learning more about PowerShell scripting see "Scripting with Windows PowerShell" at http://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx. If you plan on extensively using Windows PowerShell you may also want to take the Microsoft Official Curriculum Course 6434, "Automating Windows Server 2008 Administration with Windows PowerShell." More information about this course can be found at http://www.microsoft.com/learning/en/us/course.aspx?ID=6434A.

Because Windows PowerShell is based on Microsoft .NET technologies, it can be used within other applications to automate administrative tasks. For example, you can run PowerShell commands from within a Web page that returns information about backup status, mailbox size, or other information. More information about developing applications that use Windows PowerShell can be found in a number of locations such as "Programmatic Access via Remote PowerShell in Exchange Server 2010" at http://msexchangeteam.com/archive/2009/11/02/453016.aspx.

In addition, a software development kit (SDK) is available for Exchange Web Services (EWS). EWS provides an API to develop applications that work with data within users' mailboxes.